crq resolve and crq decline both act on a review thread. A review-body
finding, a review-skipped notice and an outside-diff remark have none, so
neither command can touch them — and drain-first then blocks every future
round on a finding that can never drain. The observed end state was a PR
reporting that no review was ever requested for its current head, four
rounds running: the round could not start because the finding was
undrained, and the finding could not drain because nothing could act on
it.

crq dismiss <repo> <pr> <finding-id>... --reason "<why>" records that the
agent judged it. Dismissed findings are withheld from the action, and
crq next reports dismissed: N so nothing looks silently dropped.

Three choices worth stating. The reason is stored, not just demanded — a
dismissal that discards its justification is not auditable. Finding IDs
are content-derived rather than GitHub node IDs, so the repo and PR are
required to identify one. And the record is scoped to the round for the
current head: the same content yields the same ID, so a dismissal that
outlived its head would silently swallow the finding when the next
reviewer reports it again. Pushing supersedes the round and clears it,
which is the rule body findings already follow.

Dismissing enqueues the PR when crq is not yet tracking the current head,
because that is the deadlock's own signature — no round for the head at
all — and a dismissal with nowhere to live would change nothing.

Three review findings, all correct.

Filtering happened in nextFromState, so a dismissal did nothing for crq
feedback or crq loop: convergence and the exit code are computed from the
full list, leaving the finding permanently actionable outside crq next.
The filter now lives in Feedback, before Converged, so there is one of it.

Nothing stopped dismissing a finding that HAS a thread. That would let a
round converge with the thread still open, skipping the resolve/decline
flow that puts the decision on the PR where the bot can answer it. A
threaded finding is now refused by name, and so is an ID that is not a
finding at this head at all — a stale copy-paste would otherwise record a
dismissal that silences whatever later matches it.

And the write is one CAS update again. Enqueueing first meant that a
failure between the enqueue and the record left a fire-eligible round
behind with nothing dismissed on it, which the autoreview daemon could
claim and spend a review on. Dismiss now reads the findings, validates
them, then creates or supersedes the round and records the decision in a
single write.

Six review findings, all correct, and three of them P1.

A round tracking a different head is now refused rather than superseded.
If the head moved after Dismiss read the findings, superseding archives
the live round and points the queue back at a commit nobody is looking
at — and CAS retries cannot protect against a mutation that deliberately
overwrites newer state.

A round may only be CREATED when this call drains the head. Dismissing
one of several open findings used to queue a fire-eligible round that
DecideFire cannot hold back, because it never sees findings — so a pump
could spend the primary's quota on code the caller is still expected to
fix.

A finding carried from an older commit is refused. IDs hash the text, not
the commit, so recording one against the current head would silently
filter the identical finding when the current reviewer reports it.

And "no thread ID" turns out not to be the question. When the GraphQL
thread query fails, Feedback falls back to REST, which does not return
thread IDs at all, so an inline comment with an open thread arrives
looking threadless. Only sources that intrinsically cannot have one —
review bodies, prompt blocks, skip notices, issue comments — are
dismissible now.

The CAS write moves to service.go as recordDismissal, which is where
AGENTS.md says every write belongs, and it honours DryRun.

Three more findings, one P1.

The eligibility guard asked whether a round object existed, when what
matters is whether a FIRE-ELIGIBLE one would. A queued round is exactly
as dangerous as a newly created one: Pump can hand it to DecideFire,
which sees no findings and cannot enforce drain-first, so dismissing one
of several open findings could still buy a review of code the caller is
still fixing.

Repeating a dismissal failed on its own earlier success: Feedback filters
the dismissed ID out, so validating against the current findings alone
rejected it as unknown. The command is documented as idempotent and an
interrupted agent repeating itself is the ordinary case, so an ID this
round already dismissed is accepted and reported as such.

And the filter now checks the SOURCE, not just the ID. Finding IDs hash
the text, not where it came from, so a dismissed body finding later
delivered as an inline comment through the REST fallback hashes the same
— and an ID-only filter would hide a review thread that is open.

Three findings, one P1 in the fix itself.

After a push the stored round is still on the PREVIOUS head, because
`crq next` returns on a current-head finding before it enqueues. Treating
that as a concurrent move rejected every dismissal and left the new head
in the exact drain-first deadlock this command exists to end. The two
cases are told apart by when the round was enqueued: after the findings
were read means somebody moved the PR forward and the decision is stale;
otherwise it is the ordinary post-push round, and it is superseded.

A finding another agent dismissed concurrently now counts as handled when
deciding whether other work is still open, instead of making this call
refuse over a finding that is already accounted for.

And the docs no longer send an agent to a command that will refuse it: a
`review_comment` finding lost its thread ID to the REST fallback, so it
is neither resolvable nor dismissible until crq can read review threads
again.

Three findings, one P1 in the guard I added last round.

FireEligible answers "right now", which is the wrong question when
deciding whether a partial dismissal would leave a round able to buy a
review. A round cooling in awaiting_retry is not eligible this second and
becomes eligible the moment RetryAt passes, so letting the dismissal
through on that technicality just deferred the hazard to the cooldown
expiring. The guard asks whether the round will ever fire again.

State alone could not tell "no round for this head" from "the head moved
and nothing has enqueued it yet", so a push landing between Feedback and
the write could record the dismissal against the wrong commit. The head is
re-read once before recording.

And the README now carries the same caveat as the skill: a review_comment
finding lost its thread ID to the REST fallback and still has an open
thread, so it is neither resolvable nor dismissible until crq can read
threads again.

A round left on the previous head can be past firing, so canStillFire said
no and the guard let a partial dismissal through — and the supersede below
then replaced it with a fresh queued round for the new head, which is exactly
the fire-eligible round the guard exists to prevent while findings are open.

Tell a stale round from a live one by Seq rather than by comparing its
EnqueuedAt against this host's clock: the fleet's hosts do not agree about
the time, and a worker whose clock lagged could supersede a newer round back
to a commit nobody is looking at.

A replay of a dismissal that already succeeded writes nothing, so it now
returns before the guard instead of being refused whenever some other finding
is still open — the command is documented as idempotent.

The dry run runs the same mutation against a throwaway copy of the state, so
it reports the ids it would record and the refusals it would hit instead of a
blanket success it cannot drift from.

Also clear the dismissal count when `crq next` finds the head moved (it is
head-scoped), and name issue-comment findings in both threadless-finding
lists, which dismissibleSources has covered all along.

The idempotence the short-circuit restores had no test that could fail:
the existing replay runs against a completed round, which the guard lets
through anyway. This one drives the case that broke — a dismissal that
ended the deadlock leaves a QUEUED round for the new head, a later review
reports something else, and the agent repeats the dismissal it does not
remember finishing — and asserts the replay is both accepted and a no-op.

A round is no longer created only by an enqueue: `crq dismiss` creates one so
the decision has somewhere to live. `crq next` read any round at all as "a
review is running for this head", so the documented fix flow — fix locally,
dismiss the threadless finding, call again — was answered `hold`, telling the
caller to sit on the very fixes it had just made until a review of the code
they replace finished. That call then enqueued and pumped, so it could buy
that review itself.

A queued round has asked for nothing: no command posted, no quota spent, and a
push supersedes it for free. Only a round that actually got as far as reserving
the slot is a review worth holding a head for.

Also count the dismissals the round recorded rather than the current findings
that still match one. A finding ID hashes the text, so a bot editing or
deleting the comment a dismissal was made against left nothing to match and
`dismissed` fell back to zero — making a finding deliberately set aside read
exactly like one that was never reported.

reviewRequested draws a line between queued and reserved, and only the
queued side is asserted. Pin the reserved one too, so a later widening of
the predicate releases a head with the command already about to be posted
and fails here instead of on a PR.